home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ien
/
ien-52
< prev
next >
Wrap
Text File
|
1988-12-01
|
6KB
|
236 lines
IEN 52 D. Cohen
Notebook Section 2.3.3.18 USC-ISI
11 August 1978
Some Thoughts About the Multiplexing Issue in Networks
------------------------------------------------------
For several years we have enjoyed the beauty and the structure offered
by the modular approach to protocols. This approach leads to the
separation of communication layers (headers, etc) according to their
originating and receiving agencies (processes, protocols etc).
It is very unfortunate that an undesired by-product of this approach is
the failure to merge communication units (messages) which have a great
deal of common communication attributes, even when they have some small
differences.
A case in point is the inability to introduce multiplexing arbitrarily
into the protocol-tree stucture.
It is intuitive that it is very desirable to be able to merge TELNET
messages between the same source/destination hosts pair, especially when
a small number of characters are communicated in each message.
Similarly, NCP and TCP messages which are addressed to the same
destination host, could be merged even though they are between different
protocols.
The same approach applies on ALL levels.
It is important to be able to use this kind of multiplexing in order to
share (and therefore save) headers, or parts of headers, and in order to
save switching time.
Consider a simple example, voice communication, using NVP through TCP
(just for the example), and internetting through the SATNet. The voice
data rate is R, and a message is sent every T time.
The amount of voice data in each message is RxT, added to that is the
NVP header of length Lv, the TCP header of length Lt, the IN header of
length Li, and the HOST/SIMP header of length Ls.
Hence, the communication efficiency is:
R x T
eff = ---------------------------
R x T + Lv + Lt + Li + Ls
Cohen [Page 1]
IEN 52 11 August 1978
Multiplexing
Assume the following numbers:
R = 2,400 bps
T = 200 milliseconds, for interactive communication
RxT = 480 bits, for a packet of voice data
Lv = 48 bits, including local-extension, time-stamp, parcels count
and silence indication.
Lt = 160 bits, including the PORT.
Li = 160 bits, (without the optional OPTIONS field)
Ls = 96 bits, according to PSPWN-100
For these numbers the efficiency is:
480 480
eff = --------------------------- = ----- = 50.8%
480 + 48 + 160 + 160 + 96 944
If N voice communications between different "extensions" in the same
hosts pair are multiplexed, then the efficiency (again, at the
interface, not in the communication media) is:
R x T
eff = ---------------------------------
R x T + Lv + (Lt + Li + Ls) / N
Which for N=2 is 65.2% and for N=3 is 72.0%. It is obvious that the
efficiency increases with N, and that in this case its limit is 90.9%.
This is, obviously, the efficiency over the HOST/SIMP interface. The
more important is the efficiency over the communication media, which is
lower than that, due to the SIMP-to-SIMP communication overhead.
Another, more familiar, example is sending a single character over the
ARPANET. In this case the payload is 8 bits, which are preceeded by 40
bit NCP header and the 96 bit HOST/IMP header. This results in
eff=8/(8+40+96)=5.5% over the interface, and even lower over the 50kbps
lines.
Just think what is the efficiency of sending a single character, or even
a few, over the SATNet... The numbers cannot be very encouraging...
Next Subject: Multi-address
---------------------------
For certain applications there is a case for multi-address, namely,
asking the communication system to deliver the same message-body to
several addresses. Mailing-lists and conferences are just two examples.
Cohen [Page 2]
IEN 52 11 August 1978
Multiplexing
The multi-address issue is the dual of the multiplexing which was
discussed earlier. Multi-address is one message-body with several
message-headers, whereas the previous muliplexing is one message-header
with several message-bodies.
Multi-address is:
<Adr1,Adr2 ; Data1> = <Adr1 ; Data1> + <Adr2 ; Data1>
Multiplexing is:
<Adr1 ; Data1,Data2> = <Adr1 ; Data1> + <Adr1 ; Data2>
Let's be (sort of) formal
-------------------------
(1) Protocol nesting is:
<msg> ::= <hdr> <body>
<hdr> ::= "type" "addr"
<body> ::= "data" ! <msg>
(2) Multiplexing is:
<msg> ::= <hdr> <body>
<hdr> ::= "type" "addr"
<body> ::= "data" ! <msgs>
<msgs> ::= <msg> ! <msgs> <msg>
(3) Multi-addressing is:
<msg> ::= <hdr> <body>
<hdr> ::= "type" "addr" ! <hdr> "addr" <body> ::= "data"
(4) Obviously the most general system is:
<msg> ::= <hdr> <body>
<hdr> ::= "type" "addr" ! <hdr> "addr" <body> ::= "data" ! <msgs>
<msgs> ::= <msg> ! <msgs> <msg>
Please consider (4) as a proposal.
Cohen [Page 3]
IEN 52 11 August 1978
Multiplexing
The point is twofold:
(1) Save overhead to reduce the number of BITs.
(2) Save overhead to reduce the number of PACKETs.
3Mbit/sec at 500 bits/packet is 6,000 packets/sec.
Today's gateways can handle 6 packets/sec, with the hope to double it by
next year..... The factor of 1,000 between these two numbers should
serve as a warning light.
Cohen [Page 4]